\subsection{Part 1}

In part 1 we generated our own personal certificate and generated a Certificate Authority for the group using our signed certificate from NTNU. We the used the group CA to generate our server certificate. In the caconf.cnf file, see appendix, we changed the key length and algorithm, explained in Q1. We edited the lifetime of the certificate to 1 year since it will only be up for the exercise period. We also edited the default values so we did not have to type them in while generating the certificate.

\paragraph{Q1}
Comment on security related issues regarding the cryptographic algorithms used to generate and sign your groups web server certiﬁcate (key length, algorithm, etc.).

\paragraph{A1}
The MD5 algorithm provided in the tutorial, is proven to not be collision resistant, meaning it is not hard to find two inputs that gives the same hashed output\cite{md5}. So we decided to use SHA1 which is less prone to output collisions. We also decided to use a keysize 2048bit instead of 1024bit. This is because OpenSSL encryption with key size 1024bit has previously been broken\cite{keysize}. By varying the voltage on a single bit in private key would be flipped by the CPU making it possible to break the encryption. 

\subsection{Part 2}
In this part we set up a Apache server secured with our certificate using SSL. First we verified the installation packages using PGP, explained in Q2.

\paragraph{Q2}
Explain what you have achieved through each of these veriﬁcations. What is the name of the person signing the Apache release?
\paragraph{A2}
When downloading the public key matching the release, we can verify that the package we have downloaded is in fact the original one. However the public key we downloaded from a public key server may be false. To make sure the key is correct we need to contact the person who has signed the key, namely William A. Rowe Jr. We did not take the time to do this.
\paragraph{}
We then moved on to setting up our group.conf file, see appendx, included in httpd.conf. We used SSLRequire to match the users certificates to grant access to various directories of the server. We also set SSLVerifyDepth = 5 to ensure that the certificate was checked to match 5 levels up, namely NTNU CA. We also made sure all file permissions where correct, explained in Q3. 

\paragraph{Q3} 
What are the access permissions to your web server’s configuration files, server certiﬁcate and the corresponding private key? Comment on possible attacks to your web server due to inappropriate file permissions.
\paragraph{A3}
Since some of the files needs to be read by the server only and some also by the users, we use permissions chmod 0600 on files read by the server only to ensure other users cannot access these on the outside. These files are the configuration files and the server private key. We use chmod 0644 on files needed to be read outside of the server, such as the certificate files. If the permissions where not set correctly the users may be able to read our private key, certificate files or our configuration files. This would give them information about how our system is protected and they could use this information to break our server security. In the worst case scenario our configuration files or certificate files where writable by the users making them able to change the permissions and get full access to our servers by removing a couple of lines of code. 

\paragraph{Q4} 
Web servers offering weak cryptography are subject to several attacks. What kind of attacks are feasible? How did you conﬁgure your server to prevent such attacks?
\paragraph{A4}
The most common attacks on weak cryptography are brute force attacks and attacks exploiting weaknesses in the encryption algorithm. Another issue is short keylengths.
Our configuration use OpenSSL with TLS 1.0. The cryptography algorithm our Apache server use to communicate with is AES-256 which is highly unlikely to be broken by a brute force attack.
AES-256 is deemed secure enough for TOP SECRET information by the U.S. Government\cite{aes_gov}.
AES has been shown to have some weaknesses because of the algorithms simple nature by Alex Biryukov and Dmitry Khovratovich\cite{aes}, which will use a lot less time to break a full AES encryption (256bit key with 14 rounds) than a brute force attack, but does still not pose a threat to the full encryption because of the time it would take to break it.
In comparison the DES algorithm has a much lower theoretical chosen plaintext of $2^{43}$ versus full AES 256 with $2^{254.4}$. However DES short key length (56 bit) has been proven to be an issue since it in 1999 was broken by distributed.net and Electronic Frontier Foundation in 22 hours and 15 minutes.
A Chosen-plaintext attack is based on that the attacker have the capability of getting the ciphertext from a number of plaintext documents which in turn can be used to break the algorithm.

\subsection{Part 3}
In this part we created several PHP files which handle login and signup of users on our webpage. We did not implement session management. We created the files:
\begin{itemize}
\item {\bf login.php} handles user login. It checks if the username and password matches a database entry. The password in the database is hashed with a hash and salt function using MD5. It also uses cookies to remember a users username.
\item {\bf signup.php} Verifies that the client is an authorized user, by checking the common name, organization name and CA of the client certificate.
\item {\bf createuser.php} is only accessible through the signup.php page by valid users and handles creation of new users. It uses the same hash function as login.php
\end{itemize}
\clearpage
\paragraph{Q5} What kind of malicious attacks is your web application (PHP) vulnerable to? Describe
them briefly, and point out what countermeasures you have developed in your code to prevent
such attacks.
\paragraph{A5}
There is a variety of attacks to consider. We chose to focus on the relevant type of attacks from the OWASP top 10 2010 \cite{owasp}.
\begin{description}
\item{\textbf{Injection}}
\begin{description}
\item{Attack: }Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter.
\item{Countermeasures: }Used method mysql\_escape\_real\_string in PHP in order to validate input.
\end{description}
\item{\textbf{Cross-Site Scripting (XSS)}}
\begin{description}
\item{Attack: }Attacker sends text-based attack scripts that exploit the interpreter in the browser. 
\item{Countermeasures: }Used method in PHP in order to validate user input.
\end{description}
\item{\textbf{Broken Authentication and Session Management}}
\begin{description}
\item{Attack: }Attacker uses leaks or flaws in the authentication or session management functions to impersonate users.
\item{Countermeasures: }Avoided using sessions for authentication and certificates in order to gain access to certain files and folders.
\end{description}
\item{\textbf{Security Misconfiguration}}
\begin{description}
\item{Attack: }Attacker accesses default accounts, unused pages, unpatched flaws, unprotected files and directories, etc. to gain unauthorized access to or knowledge of the system.
\item{Countermeasures: }A strong application architecture that provides good separation and security between components.
\end{description}
\item{\textbf{Failure to Restrict URL Access}}
\begin{description}
\item{Attack: }Attacker, who is an authorized system user, simply changes the URL to a privileged page.
\item{Countermeasures: }System checks for certificates and uses SSLRequire.
\end{description}
\end{description}

\subsection{Part 4}
In this part we set up a SVN repository on our server. We also moved the webpage to this repository and altered the root of our webpage to the new location.
\paragraph{Q6}
Describe the security measures you have undertaken to secure your repository, and how did that affect the security of your Web Application (Better? Worse?). Elaborate on the possible further measures, that can prevent certain types of attacks you found possible in the setting you created. Can you discover any vulnerabilities in the other groups projects? If so, try to mount attacks on other groups!
\paragraph{Q6}
Our repository is secured with a username/password mechanism. This may compromise the security of our server, since if a user gets hold of our username/password, they would get full access to all of our published files. We could also make the repository more secure by making it only accessible over SSH. This setup is prone to hammering, or a brute force attack trying out combinations of username/passwords.

However we turned off the password protection of our repository to do some testing and forgot to turn it back on. This gave all other users access to all of our files, including the files handling the MYSQL-connection where we had stored our password in plaintext. Since this password is the same as the password for our group, this gave a group full access to our server.
